home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1993…ch: Other People's Memory / ADC Developer CD (1993-03) (''Other People's Memory'')_iso / Dev.CD Mar 93.iso / Development Platforms / CSMP Digests / csmp-v1-048.txt < prev    next >
Encoding:
Text File  |  1992-11-18  |  57.5 KB  |  1,556 lines  |  [TEXT/MPS ]

  1. C.S.M.P. Digest             Sun, 12 Apr 92       Volume 1 : Issue 48
  2.  
  3. Today's Topics:
  4.  
  5.     TMON 3.0 secret about screen
  6.     Think C 5.0.2 & sprintf
  7.     Whatever Happend to Vol 2: Internet Prog. Guide?
  8.     Big Arrays in Think C
  9.     Radius and AppleTalk PROBLEMS - Anyone else?
  10.     Big Pictures
  11.     OZ & NZ: Pictoids Package 1.0 NOW AVAILABLE for ftp
  12.     Speaker-independent continuous-speech recognition on a Mac !?
  13.  
  14.  
  15. The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.
  16.  
  17. These digests are available (by using FTP, account anonymous, your email
  18. address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
  19. edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
  20. Questions list.
  21.  
  22. These digests are also available via email.  Just send a note saying that you
  23. want to be on the digest mailing list to mkelly@cs.uoregon.edu, and you will
  24. automatically receive each new digest as it is created.
  25.  
  26. The articles in these digests are taken directly from comp.sys.mac.programmer.
  27. They are not edited; all articles included in this digest are in their original
  28. posted form.  The only articles that are -not- included in these digests are
  29. those which didn't receive any replies (except those that give information
  30. rather than ask a question).  All replies to each article are concatenated
  31. onto the original article in the order in which they were received.  Article
  32. threads are not added to the digests until the last article added to the
  33. thread is at least one month old (this is to ensure that the thread is dead
  34. before adding it to the digests).
  35.  
  36. Send administrative mail to mkelly@cs.uoregon.edu.
  37.  
  38. -------------------------------------------------------
  39.  
  40. From: neal@farallon.com (Neal Trautman)
  41. Subject: TMON 3.0 secret about screen
  42. Date: 9 Mar 92 15:30:21 GMT
  43. Organization: Farallon Computing, Inc.
  44.  
  45. >From the MacHack 1991 Hack Contest Stack:
  46. >TMON 3.0 secret about screen
  47. >The TMON 3.0 application loader has a cool secret about screen.
  48. >Be the first to find it and read it, and you will win a prize!
  49. >  Waldemar Horwat
  50.  
  51. Well, simply goto the about dialog and wait for 3 minutes.
  52. Or you can patch the _Alert filter so you don't have to wait
  53. so long.  This is left as an excercise for the student.  :-)
  54.  
  55. - -- Neal Trautman
  56. Timbuktu Lead Software Engineer
  57. Farallon Computing, Inc.
  58. neal@farallon.com
  59.  
  60. ---------------------------
  61.  
  62. From: jack@umbio.med.miami.edu (Jack Herrington)
  63. Subject: Think C 5.0.2 & sprintf
  64. Date: 8 Mar 92 02:04:00 GMT
  65. Organization: University Of Miami, Biomedical Computing
  66.  
  67. I'm almost embarrased to say I have this problem, but I'm using Think C
  68. 5.0.2, and I'm tring to sprintf(charTmp,"%g",tempFloat).  And it aint
  69. working, and it isn't the value of the variable.  I've tried setting on
  70. the line above.
  71.  
  72. I've programmed almost the entire program, minus this stupid little glitcho.
  73.  
  74. I noticed that ANSI had 'use native floating point' off and my starter
  75. project (in object) had it on, but when I flipped it, still no luck.  In
  76. fact I checked everything, I looked at the code, at all the options, and
  77. I'm mega-stumped.
  78.  
  79. Any help would be greatly appreciated.
  80. - -- 
  81. "Electric word 'life', it means forever and that's a might long time.  But I'm
  82.  here to tell yah, there's something else... The after-life, a word of
  83.  never-ending happiness, you can always see the sun, day or night.  So when you
  84.  call up that shrink in Beverly hills, you know the one, Dr. everything-we-all-
  85.  
  86. +++++++++++++++++++++++++++
  87.  
  88. From: ericd@CATICSUF.CSUFRESNO.EDU (Eric W. Douglas)
  89. Date: 8 Mar 92 08:18:34 GMT
  90.  
  91.  
  92. jack@umbio.med.miami.edu (Jack Herrington) writes:
  93.  
  94. >I'm almost embarrased to say I have this problem, but I'm using Think C
  95. >5.0.2, and I'm tring to sprintf(charTmp,"%g",tempFloat).  And it aint
  96. >working, and it isn't the value of the variable.  I've tried setting on
  97. >the line above.
  98.  
  99. >I've programmed almost the entire program, minus this stupid little glitcho.
  100.  
  101. >I noticed that ANSI had 'use native floating point' off and my starter
  102. >project (in object) had it on, but when I flipped it, still no luck.  In
  103. >fact I checked everything, I looked at the code, at all the options, and
  104. >I'm mega-stumped.
  105.  
  106. I too have had problems with 'sprintf()'... except I was writing code
  107. resources, and getting plain old address errors... I allocated memory,
  108. stepped through machine code... couldn't figure it out...
  109.  
  110. I seem to remember that there was an update posted on CServe or America
  111. OnLine to the function, but it didn't alleviate my problem.
  112.  
  113. - --eric
  114.  
  115. * | Eric W. Douglas             Technojock               +1 209 897 5785 | *
  116. * | I'net: ericd@caticsuf.csufresno.edu      ericd@csufres.csufresno.edu | *
  117. * | AppleLink: STUDIO.D      Compuserve: 76170,1472       AOL: EWDOUGLAS | *
  118. * |                "if q -> p, and not p, then not q. NOT!"              | * 
  119.  
  120. +++++++++++++++++++++++++++
  121.  
  122. From: rla20@duts.ccc.amdahl.com (Roger Allen)
  123. Date: 10 Mar 92 18:57:23 GMT
  124. Organization: Amdahl Corporation, Sunnyvale CA
  125.  
  126. >I'm almost embarrased to say I have this problem, but I'm using Think C
  127. >5.0.2, and I'm tring to sprintf(charTmp,"%g",tempFloat).  And it aint
  128. >working, and it isn't the value of the variable.  I've tried setting on
  129. >the line above.
  130.  
  131. try 
  132.    sprintf(charTmp,"%lg",tempFloat), 
  133. or sprintf(charTmp,"%hg",tempFloat)
  134.  
  135. I seem to recall having trouble with this before...
  136.  
  137. Roger
  138. - --
  139. > Roger Allen                   |  All the opinions expressed are my     <
  140. > Amdahl Computer Development   |  own and are not Amdahl's.             <
  141. > rla20@cd.amdahl.com           |  ------They paid me to say that------- <
  142.  
  143. +++++++++++++++++++++++++++
  144.  
  145. From: jack@umbio.med.miami.edu (Jack Herrington)
  146. Date: 10 Mar 92 21:54:47 GMT
  147. Organization: University Of Miami, Biomedical Computing
  148.  
  149. The problem is fixed.  It was that I was having trouble using 'sprint'
  150. with a floating point arguement.  The lesson to be learned is to watch the
  151. option switches when loading in a project, like 'ANSI'.  The standard
  152. 'ANSI' uses non-native floating pointer, the 'Starter' OOP project uses
  153. native floating point.  Be forewarned.
  154. - -- 
  155. "Electric word 'life', it means forever and that's a might long time.  But I'm
  156.  here to tell yah, there's something else... The after-life, a word of
  157.  never-ending happiness, you can always see the sun, day or night.  So when you
  158.  call up that shrink in Beverly hills, you know the one, Dr. everything-we-all-
  159.  
  160. ---------------------------
  161.  
  162. From: Jim Cook <J.Cook@ENS.Prime.COM>
  163. Subject: Whatever Happend to Vol 2: Internet Prog. Guide?
  164. Organization: Prime Computer, Inc.
  165. Date: Mon, 9 Mar 1992 17:23:31 GMT
  166.  
  167. Whatever happened to the followons to the Internet Programmers Guide?
  168. I remember reading something that said both volume II and volume II were
  169. both in the works due to the amount of material.  I tried sending email
  170. to the author - I believe it was Matthew Xavier Mora - but I haven't 
  171. received a reply or a bounced message.  Anyone know anything for real?
  172.  
  173. Jim
  174. <J.Cook@ENS.Prime.COM>
  175.  
  176.  
  177. +++++++++++++++++++++++++++
  178.  
  179. From: mxmora@unix.SRI.COM (Matt Mora)
  180. Date: 9 Mar 92 19:05:58 GMT
  181. Organization: SRI International, Menlo Park, California
  182.  
  183. In article <1992Mar9.172331.14845@primerd.prime.com> J.Cook@ENS.Prime.COM (Jim Cook) writes:
  184. >Whatever happened to the followons to the Internet Programmers Guide?
  185. >I remember reading something that said both volume II and volume II were
  186. >both in the works due to the amount of material.  I tried sending email
  187. >to the author - I believe it was Matthew Xavier Mora - but I haven't 
  188. >received a reply or a bounced message.  Anyone know anything for real?
  189.  
  190. I'm still here, and yes I am working on it. I haven't been able to spend any
  191. time on it lately because of other projects I am working on. I hope to have 
  192. the next version(s) out in time for the WWDC in may.
  193.  
  194. Sorry for the delay,
  195.  
  196. Matt
  197.  
  198.  
  199.  
  200. - -- 
  201. ___________________________________________________________
  202. Matthew Mora                |   my Mac  Matt_Mora@sri.com
  203. SRI International           |  my unix  mxmora@unix.sri.com
  204. ___________________________________________________________
  205.  
  206. ---------------------------
  207.  
  208. From: sgrenander@NASAMAIL.JPL.NASA.GOV (Sven Grenander)
  209. Subject: Big Arrays in Think C
  210. Date: 9 Mar 92 21:39:35 GMT
  211. Organization: Jet Propulsion Laboratory
  212.  
  213. There have been a number of suggestions for getting large arrays
  214. in ThC.
  215.  
  216. What am I missing ? Why not just use Calloc as suggested in
  217. K&R ? You can still index away to your hearts content (array[372][2569]).
  218.  
  219. Gets a bit messy when you have arrays of arrays of arrays, but no
  220. real problem.
  221.  
  222. - -Sven
  223.  
  224. +++++++++++++++++++++++++++
  225.  
  226. From: frain@cis.ksu.edu (Jerry Frain)
  227. Date: 9 Mar 92 22:50:51 GMT
  228. Organization: Kansas State University
  229.  
  230. sgrenander@NASAMAIL.JPL.NASA.GOV (Sven Grenander) writes:
  231.  
  232. > There have been a number of suggestions for getting large arrays
  233. > in ThC.
  234.  
  235. > What am I missing ? Why not just use Calloc as suggested in
  236. > K&R ? You can still index away to your hearts content (array[372][2569]).
  237.  
  238. > Gets a bit messy when you have arrays of arrays of arrays, but no
  239. > real problem.
  240.  
  241. Accessing dynamically allocated memory as arrays > 1 dimension can get
  242. messy, since you have to compute the location you wish to reference
  243. when it is normally done manually.
  244.  
  245. Consider the following two arrays, each of 12 integers:
  246.  
  247.     int a[3][4], b[2][6];
  248.  
  249. It should be quite obvious that
  250.  
  251.     a[2][0]
  252.  
  253. references the 6th location (starting at 0, of course) of a's space,
  254. since a[2][0] is really a[(2*3)+0] == a[6], if a were linear.
  255.  
  256. Likewise,
  257.  
  258.     b[2][0]
  259.  
  260. references the 4th location of b's space, since b[2][2] is really
  261. b[(2*2)+0] == b[4] if b were linear.
  262.  
  263. Now, when I allocate the following linear memory space,
  264.  
  265.     int *c;
  266.     c = (int *) malloc(sizeof(int) * 12);
  267.  
  268. which location should c[2][0] reference?
  269.  
  270. The answer is, the C compiler should give you an error because the
  271. dimensions of the space are unknown (actually it's linear, and thus
  272. cannot be calculated for multiple dimensions).
  273.  
  274.   --Jerry Frain, frain@cis.ksu.edu
  275.  
  276. +++++++++++++++++++++++++++
  277.  
  278. From: wolf@ascari.cipl.uiowa.edu (Michael J. Wolf)
  279. Date: 10 Mar 92 13:18:04 GMT
  280. Organization: Cardiovascular Image Processing Lab, U of Iowa
  281.  
  282. In article <frain.700182872@aleph.cis.ksu.edu> frain@cis.ksu.edu (Jerry Frain) writes:
  283. >sgrenander@NASAMAIL.JPL.NASA.GOV (Sven Grenander) writes:
  284. >
  285. >> There have been a number of suggestions for getting large arrays
  286. >> in ThC.
  287. >
  288. >> What am I missing ? Why not just use Calloc as suggested in
  289. >> K&R ? You can still index away to your hearts content (array[372][2569]).
  290. >
  291. >> Gets a bit messy when you have arrays of arrays of arrays, but no
  292. >> real problem.
  293. >
  294. >Accessing dynamically allocated memory as arrays > 1 dimension can get
  295. >messy, since you have to compute the location you wish to reference
  296. >when it is normally done manually.
  297. >
  298.  
  299. It would noty be messy at all.  You could call calloc for the correct memory
  300. block size and you could use something like the following to do so:
  301.  
  302. int    *data[x][y]...;
  303.  
  304. The above would then be a n dimensional array of pointers to ints.  So if you
  305. wanted 3 dimensions you could simple declare:
  306.  
  307. int    *data[x][y];
  308.  
  309. Then calloc the memory for the above data.  Then you can index like a 3D array.
  310.  
  311. With Mac memory manager, you can allocate large handles and declare a type that
  312. is a pointer to an array with the dimensions you wish, then declare a handle
  313. which uses the pointer.
  314.  
  315. Just one mans opinions
  316.  
  317. MJW
  318.  
  319. =+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=
  320.  Michael J. Wolf                    | 
  321.  Software Engineer                  | McIntosh Jr.:
  322.  Cardiovascular Image Processing Lab|   The Power To Crush The Other Kids
  323.  University of Iowa                 |
  324.  wolf@fangio.cipl.uiowa.edu         |Disclaimer?  Hell, I don't even know her!
  325. =+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=
  326.  
  327.  
  328. +++++++++++++++++++++++++++
  329.  
  330. From: duga@merlin.cvs.rochester.edu (Brady Duga)
  331. Date: 10 Mar 92 13:45:51 GMT
  332. Organization: University of Rochester, Rochester NY
  333.  
  334.  
  335. One way around this (particularly easy for 2D arrays) would be to store
  336. the length of a row at the head of the array and write a function (or macro)
  337. which returns the correct element. Something like:
  338.  
  339. int  *a,*b;  //Where 'a' should be a[2][3] and 'b' should be b[3][2]
  340.  
  341. a=malloc(sizeof(int) * (2*3 + 1));
  342. a[0]=3;
  343. b=malloc(sizeof(int) * (3*2 + 1));
  344. b[0]=2;
  345.  
  346. Then the function:
  347.  
  348. GetIndex(arr,x,y)
  349. int *arr,x,y;
  350. {
  351.    return y*arr[0] + x;
  352. }
  353.  
  354. You could use similar functions to get and set the value of an element. This
  355. makes ther linear array approach much less messy.
  356.  
  357. - --Brady (duga@cvs.rochester.edu)
  358.  
  359. +++++++++++++++++++++++++++
  360.  
  361. From: bruner@sp15.csrd.uiuc.edu (John Bruner)
  362. Organization: CSRD, University of Illinois
  363. Date: 10 Mar 92 09:54:12
  364.  
  365. In article <frain.700182872@aleph.cis.ksu.edu> frain@cis.ksu.edu (Jerry Frain) writes:
  366. > Consider the following two arrays, each of 12 integers:
  367. >     int a[3][4], b[2][6];
  368. > It should be quite obvious that
  369. >     a[2][0]
  370. > references the 6th location (starting at 0, of course) of a's space,
  371. > since a[2][0] is really a[(2*3)+0] == a[6], if a were linear.
  372.  
  373. Actually (as I'm sure you know) it is the 8th location (starting at 0)
  374.  
  375. This subject comes up from time to time.
  376.  
  377. If you want to allocate a large array with fixed dimensions
  378. N1,N2,N3,...,Nn the easiest way is to declare a pointer to an array
  379. with dimensions N2,N3,...Nn.  In this case:
  380.  
  381.     int (*a)[4];
  382.  
  383. You can allocate space with
  384.  
  385.     a = malloc(3 * sizeof *a);
  386.  
  387. and can refer to elements as a[i][j].
  388.  
  389. If you want the code to reflect the explicit allocation, you can also
  390. declare a pointer to an array with dimensions N1,N2,N3,...Nn
  391.  
  392.     int (*a)[3][4];
  393.  
  394. allocate space with
  395.  
  396.     a = malloc(sizeof *a);
  397.  
  398. and refer to elements as (*a)[i][j];
  399. - --
  400. (Dr.) John Bruner, Deputy Director            bruner@csrd.uiuc.edu
  401. Center for Supercomputing Research & Development    (217) 244-4476 (voice)
  402. University of Illinois at Urbana-Champaign        (217) 244-1351 (FAX)
  403. 305 Talbot Laboratory; 104 South Wright St.; Urbana, IL  61801
  404.  
  405. +++++++++++++++++++++++++++
  406.  
  407. From: alen@crash.cts.com (Alen Shapiro)
  408. Date: 10 Mar 92 15:25:55 GMT
  409. Organization: Crash TimeSharing, El Cajon, CA
  410.  
  411. In <frain.700182872@aleph.cis.ksu.edu> frain@cis.ksu.edu (Jerry Frain) writes:
  412.  
  413. >sgrenander@NASAMAIL.JPL.NASA.GOV (Sven Grenander) writes:
  414.  
  415. >> There have been a number of suggestions for getting large arrays
  416. >> in ThC.
  417.  
  418. >> What am I missing ? Why not just use Calloc as suggested in
  419. >> K&R ? You can still index away to your hearts content (array[372][2569]).
  420.  
  421. >> Gets a bit messy when you have arrays of arrays of arrays, but no
  422. >> real problem.
  423.  
  424. >Accessing dynamically allocated memory as arrays > 1 dimension can get
  425. >messy, since you have to compute the location you wish to reference
  426. >when it is normally done manually.
  427.  
  428. ...example of a mess deleted...
  429.  
  430. Try building a real array on the heap...as follows:
  431.  
  432. #include <stdio.h>
  433. #include <stdlib.h>
  434.  
  435. void *
  436. ccalloc(elems, sz)
  437.         size_t elems, sz; {
  438.         void *mptr = calloc(elems, sz);
  439.  
  440.         if(mptr == (void *)NULL) {
  441.                 fprintf(stderr, "calloc failed\n");
  442.                 exit(1);
  443.         }
  444.         return(mptr);
  445. }
  446.  
  447. void **
  448. two_d_array(x, y, el_size)
  449.     size_t el_size; {
  450.         int i;
  451.         void **arr = (void **)ccalloc((size_t)x, sizeof(void *));
  452.  
  453.         for(i=0 ; i < x ; i++)
  454.                 arr[i] = (void **)ccalloc((size_t)y, el_size);
  455.         return(arr);
  456. }
  457.  
  458. main() {
  459.         long **enc, **permenc;
  460.  
  461.         enc = (long **)two_d_array(4, 4096, sizeof(long));
  462.         permenc = (long **)two_d_array(4, 4096, sizeof(long));
  463.  
  464.         enc[2][5] = (long)1;
  465.         fprintf(stdout, "%ld %ld %ld\n", enc[2][4], enc[2][5], enc[2][6]);
  466. }
  467.  
  468. - --alen
  469. alen@crash.cts.com
  470.  
  471. ps you will also have to build a "2_d_free()" but that is easy :-)
  472. pps beware for portability when either <x>*(sizeof(void *)) >= 65536
  473.     or when <y>*el_size >= 65536--compilers with 16-bit ints and
  474.     calloc args of "unsigned" may blow-up above these limits (THINK_C
  475.     does not qualify ... i.e. does NOT blow up).
  476.  
  477. +++++++++++++++++++++++++++
  478.  
  479. From: suitti@ima.isc.com (Stephen Uitti)
  480. Date: 10 Mar 92 20:14:36 GMT
  481. Organization: Interactive Systems, Cambridge, MA 02138-5302
  482.  
  483. In article <1992Mar9.213935.8508@elroy.jpl.nasa.gov> sgrenander@NASAMAIL.JPL.NASA.GOV (Sven Grenander) writes:
  484. >There have been a number of suggestions for getting large arrays
  485. >in ThC.
  486. >What am I missing ? Why not just use Calloc as suggested in
  487. >K&R ? You can still index away to your hearts content (array[372][2569]).
  488.  
  489. In Think C 3, malloc() took an int for the size of the object,
  490. thus was limited to 32K or 64.  lmalloc() took a long, and could
  491. be used as suggested.  Think Think C 5, malloc() takes a size_t,
  492. which is fine.  This has to do with the evolution of the
  493. language, rather than the compiler.  At the time Think C 3 was
  494. around, malloc() was documented (why?) to take an int.  At that
  495. time, it was generally assumed that int was big enough to hold a
  496. character pointer.  It was true on a VAX, and it was true on a
  497. PDP-11.  I don't happen to know how Think C 4 does it.  NewPtr()
  498. and malloc() are functionally equivalent.  Calloc() clears the
  499. array first, which may or may not be what you want.  Calloc() may
  500. be painful with virtual memory, if initialiation is not required.
  501.  
  502. Stephen.
  503. suitti@ima.isc.com
  504.  
  505. ---------------------------
  506.  
  507. From: jwinterm@jarthur.claremont.edu (Jim Wintermyre)
  508. Subject: Radius and AppleTalk PROBLEMS - Anyone else?
  509. Date: 10 Mar 92 02:47:04 GMT
  510. Organization: Harvey Mudd College
  511.  
  512.  
  513. Hi.  I am working on a program (INIT/driver/DA combo) that uses AppleTalk.
  514. Basically, it allows people to talk to each other over a network in real
  515. time.  The problem I'm having is that on ONE machine I've tried it on,
  516. I can't seem to open the AppleTalk drivers at INIT time correctly.  This
  517. machine is a Mac IIx with 8 megs of RAM and a Radius Two-Page Display.
  518. Some people I've talked to mentioned having experinced similar problems
  519. with AppleTalk and Radius monitors.  Has anyone else had this problem?
  520. Does anyone know what causes it?  Anyone at Radius have any ideas?
  521.  
  522. Thanks for any help,
  523.  
  524. Jim Wintermyre
  525. jwinterm@jarthur.claremont.edu
  526.  
  527. +++++++++++++++++++++++++++
  528.  
  529. From: orpheus@reed.edu (P. Hawthorne)
  530. Date: 10 Mar 92 08:04:20 GMT
  531. Organization: Reed College, Portland OR
  532.  
  533.  
  534.   jwinterm@jarthur.claremont.edu (Jim Wintermyre) writes:
  535. : The problem I'm having is that on ONE machine I've tried it on,
  536. : I can't seem to open the AppleTalk drivers at INIT time correctly.  
  537. : Some people I've talked to mentioned having experinced similar problems
  538. : with AppleTalk and Radius monitors.  Has anyone else had this problem?
  539.  
  540.   Five will get you ten that this one machine just happens to have lost the
  541. special Radius AppleTalk kludge init that all the others have in their
  542. system folders. If that init is loading and your init continues to fail,
  543. all bets are off and quite possibly, short of a total system overhaul, only
  544. Radius itself could help you out. Best wishes,
  545.  
  546.   Weighing broad compatibility against delay until entry,
  547.   Theus (orpheus@reed.edu)
  548.  
  549. +++++++++++++++++++++++++++
  550.  
  551. From: amichiel@rodan.acs.syr.edu (Allen J Michielsen)
  552. Date: 10 Mar 92 21:56:55 GMT
  553. Organization: Syracuse University, Syracuse, NY
  554.  
  555.  
  556. - --
  557. Al. Michielsen, Mechanical & Aerospace Engineering, Syracuse University
  558.  InterNet: amichiel@mailbox.syr.edu  amichiel@sunrise.acs.syr.edu
  559.  Bitnet: AMICHIEL@SUNRISE 
  560.  
  561. ---------------------------
  562.  
  563. From: nagle@netcom.com (John Nagle)
  564. Subject: Big Pictures
  565. Date: Tue, 10 Mar 92 19:00:02 GMT
  566. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  567.  
  568.      With Color QuickDraw, can picture recording via OpenPicture/
  569. ClosePicture record pictures greater than 32K bytes?  IM V-86
  570. seems to indicate that it can, but never quite says it.  
  571.  
  572.      If you run out of memory while recording a picture under ColorQuickDraw,
  573. what happens?  One hopes they improved on the old approach of simply
  574. overwriting memory.
  575.  
  576.                     John Nagle
  577.  
  578. +++++++++++++++++++++++++++
  579.  
  580. From: jcav@quads.uchicago.edu (JohnC)
  581. Date: 10 Mar 92 21:05:38 GMT
  582. Organization: The Royal Society for Putting Things on Top of Other Things
  583.  
  584. In article <kb2h0y_nagle@netcom.com> nagle@netcom.com (John Nagle) writes:
  585. >     With Color QuickDraw, can picture recording via OpenPicture/
  586. >ClosePicture record pictures greater than 32K bytes?  IM V-86
  587. >seems to indicate that it can, but never quite says it.  
  588.  
  589. It doesn't need to, since the 32K restriction was lifted with the advent of
  590. the Mac Plus 128K ROMs, documented in IM-IV. ;-)  Check out page 23 of said
  591. volume, where it also talks about how to test if you've run out of memory
  592. while creating a picture.
  593.  
  594.  
  595. - -- 
  596. John Cavallino                  |  EMail: jcav@midway.uchicago.edu
  597. University of Chicago Hospitals |         John_Cavallino@uchfm.bsd.uchicago.edu
  598. Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
  599. B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637
  600.  
  601. ---------------------------
  602.  
  603. Subject: OZ & NZ: Pictoids Package 1.0 NOW AVAILABLE for ftp
  604. From: news@massey.ac.nz (USENET News System)
  605. Date: Tue, 10 Mar 1992 20:54:46 GMT
  606. Organization: School of Maths & Info. Sci., Massey University, Palmerston North, NZ
  607.  
  608.  
  609. Thanks to the help of Hal Miller, OZ & NZ folks don't need to wait for
  610. Pictoids Package 1.0 to work its way through the queues at rascal and
  611. hence onto sumex etc. The package is now avialable for ftp from
  612. shark.mel.dit.csiro.au (144.110.16.11) in pub/Pictoids_1.0.hqx. This
  613. copy will be removed when Pictoids reaches sumex as shark is a sumex
  614. shadow, it should then reappear in shark's sumex space.
  615.  
  616. Enjoy!
  617.  
  618. Nigel
  619.  
  620. - -- 
  621. - ---
  622. Dr Nigel Perry                    Email: N.Perry@massey.ac.nz
  623. Department of Computer Science    Tel: +64 6 356 9099 ext 8900
  624. Massey University                 Fax: +64 6 350 5611
  625. Palmerston North
  626. New Zealand
  627.  
  628. ---------------------------
  629.  
  630. From: mitsu@nic.cerf.net (Mitsuharu Hadeishi)
  631. Subject: Speaker-independent continuous-speech recognition on a Mac !?
  632. Date: 25 Feb 92 17:57:26 GMT
  633. Organization: CERFnet
  634.  
  635.  
  636.     The Wall Street Journal yesterday, Monday, 2/24/92,
  637. apparently ran an article about *speaker-independent continuous
  638. speech recognition* running on a MACINTOSH.  It said, according
  639. to what I've heard, that sometime last week John Sculley
  640. demonstrated the technology at some conference.  WHAT THE HELL
  641. IS GOING ON HERE!?  Anyone else have more information on this
  642. development?  This is, naturally, a rather major piece of news,
  643. depending on how true it is.  I'm sure it is not nearly as
  644. impossible-sounding as it sounds, but I'd like to know just
  645. how powerful this technology is (vocabulary size, speed,
  646. etc.)  Who developed this?  Is it based on any existing
  647. speech-recognition theory (Hidden Markov Models, neural-network
  648. based solutions, etc.), or what?
  649.  
  650.     Apple Link is no help; they just posted a single
  651. paragraph from the article.  Anybody else care to shed some
  652. light on this?
  653.  
  654.  
  655.  
  656. - -------------------------
  657.  
  658. From: rla20@duts.ccc.amdahl.com (Roger Allen)
  659. Subject:  Speaker-independent continuous-speech recognition on a Mac !?
  660. Date: 25 Feb 92 19:19:35 GMT
  661. Organization: Amdahl Corporation, Sunnyvale CA
  662.  
  663. In article <1463@nic.cerf.net> mitsu@nic.cerf.net (Mitsuharu Hadeishi) writes:
  664. >
  665. >    The Wall Street Journal yesterday, Monday, 2/24/92,
  666. >apparently ran an article about *speaker-independent continuous
  667. >speech recognition* running on a MACINTOSH
  668. ...
  669. >etc.)  Who developed this?  Is it based on any existing
  670. >speech-recognition theory (Hidden Markov Models, neural-network
  671. >based solutions, etc.), or what?
  672. >
  673.  
  674. The article stated that the head developer is Kai-fu Lee who was
  675. hired away from Carnegie-Mellon (sp?) University where he did
  676. research on (you guessed it!) continuous speech voice recognition.
  677. The project at CMU was called Sphinx, I believe, and used custom
  678. hardware.  It seems he has now optimized his algorithms for the '040.
  679.  
  680. Any comment from the peanut gallery on the CMU Sphinx project?   That
  681. would be the closest thing I would imagine.
  682.  
  683. Another thing I thought was neat was that you had to address the computer
  684. before giving a command.  Gee! Just like Scotty in Star Trek V!
  685. I hope Paramount doesn't sue Apple because it is infringing on the
  686. "look-and-feel" that it developed.
  687.  
  688. This sounds just incredible, but then again so did cold fusion.
  689. --
  690. > Roger Allen                   |  All the opinions expressed are my     <
  691. > Amdahl Computer Development   |  own and are not Amdahl's.             <
  692. > rla20@cd.amdahl.com           |  ------They paid me to say that------- <
  693.  
  694.  
  695.  
  696. - -------------------------
  697.  
  698. From: blimoges@sobeco.com (Bertrand Limoges)
  699. Subject:  Speaker-independent continuous-speech recognition on a Mac !?
  700. Organization: Sobeco Ernst & Young Inc.
  701. Date: Tue, 25 Feb 1992 19:48:22 GMT
  702.  
  703. In article <1463@nic.cerf.net>, Mitsuharu Hadeishi writes:
  704. >     The Wall Street Journal yesterday, Monday, 2/24/92,
  705. > apparently ran an article about *speaker-independent continuous
  706. > speech recognition* running on a MACINTOSH.
  707. .. [stuff deleted]
  708. > depending on how true it is.  I'm sure it is not nearly as
  709. > impossible-sounding as it sounds, but I'd like to know just
  710. > how powerful this technology is (vocabulary size, speed,
  711. > etc.)  Who developed this?  Is it based on any existing
  712. > speech-recognition theory (Hidden Markov Models, neural-network
  713. > based solutions, etc.), or what?
  714.  
  715.  
  716. The info I have is from MacWeek 02.03.92:
  717. 1. The project is code-named Casper and runs on a Quadra 900
  718.    souped-up with a digital signal processor (DSP) and a better
  719.    microphone then the standard one shipped with the Macs.
  720. 2. Vocabulary is more than 100,000 words.
  721. 3. System designed by "sampling hundreds of different voices in a
  722.    wide range of accents, tones and pitches."
  723. 4. DSP and mike are likely to be incorporated in new Quadra model
  724.    by year end.
  725. 5. Currently requires 1 MB RAM.
  726. 6. Problems with "nuances' of speech, such as hesitations...
  727.    Big surprise! 8-)
  728. 7. Developped by Apple.
  729.  
  730. No info on innards 8-(   Hopes this helps, Bertrand Limoges
  731.  
  732.  
  733.  
  734. - -------------------------
  735.  
  736. From: khaw@parcplace.com (Mike Khaw)
  737. Subject:  Speaker-independent continuous-speech recognition on a Mac !?
  738. Date: 25 Feb 92 19:44:50 GMT
  739.  
  740. I haven't seen the WSJ article. I started to skim a short article in
  741. the San Jose Mercury (2/25/92) about it, but lost interest when I read
  742. where it said something about speaker-independent discrete word
  743. recognition from a limited/restricted vocabulary.
  744. --
  745. Michael Khaw - Domain=khaw@parcplace.com, UUCP=...!uunet!parcplace!khaw
  746. ParcPlace Systems, Inc., 1550 Plymouth St., Mountain View, CA 94043
  747.  
  748.  
  749.  
  750. - -------------------------
  751.  
  752. From: norman@a.cs.okstate.edu (Norman Graham)
  753. Subject:  Speaker-independent continuous-speech recognition on a Mac !?
  754. Date: 25 Feb 92 19:37:22 GMT
  755. Organization: Oklahoma State University
  756.  
  757. In article <1463@nic.cerf.net> mitsu@nic.cerf.net (Mitsuharu Hadeishi) writes:
  758. >
  759. >    The Wall Street Journal yesterday, Monday, 2/24/92,
  760. >apparently ran an article about *speaker-independent continuous
  761. >speech recognition* running on a MACINTOSH.  It said, according
  762. >to what I've heard, that sometime last week John Sculley
  763. >demonstrated the technology at some conference.  WHAT THE HELL
  764. >IS GOING ON HERE!?  Anyone else have more information on this
  765. >development?  This is, naturally, a rather major piece of news,
  766. >depending on how true it is.  I'm sure it is not nearly as
  767. >impossible-sounding as it sounds, but I'd like to know just
  768. >how powerful this technology is (vocabulary size, speed,
  769. >etc.)  Who developed this?  Is it based on any existing
  770. >speech-recognition theory (Hidden Markov Models, neural-network
  771. >based solutions, etc.), or what?
  772.  
  773. In the Feb 3 issue of MacWeek, there's a front page report of a 
  774. preview of this technology given at Demo '92 the prior week. The preview
  775. was given by David Nagel, Apple's Senior VP of the Advanced Technology
  776. Group. 
  777.  
  778. Casper (apparently this technology's code name) was running demo'd
  779. on a Quadra 900 enhanced with a digital signal processor (DSP) and 
  780. a better microphone than Apple is now shipping. By year's end, the
  781. DSP and new microphone are expected to be included in a new Quadra
  782. model.
  783.  
  784. Casper's vocabulary is greater than 100,000 words. It appears that
  785. larger vocabularies need more processing power, so expect a some-
  786. what smaller vocabulary on less powerful machines.
  787.  
  788. Casper needs about 1 MB of RAM, but Nagle expects to half that
  789. requirement before Casper ships.
  790.  
  791. No details were given on the implementation technology. I seem to
  792. recall seeing a QuickTime video showing a 3D analysis of speech
  793. that the Casper team is using, but I don't recall what the axis 
  794. represented. I also seem to recall reading something that said
  795. the Casper group has taken samples of thousands of people speaking
  796. and they somehow extract essential characteristics of words from
  797. all these samples. This explains why users don't need to train
  798. Casper--the group has already done it.
  799.  
  800. Disclaimer: I have no knowledge of how speech recognition works,
  801. so don't be surprised if the above is not accurate. 
  802. -- 
  803. Norman Graham
  804.  
  805. <norman@a.cs.okstate.edu>                 Standard Disclaimer Applies
  806. {cbosgd,rutgers}!okstate!norman
  807.  
  808.  
  809.  
  810. - -------------------------
  811.  
  812. From: jb@lexicon.com (Jim Bailey)
  813. Subject:  Speaker-independent continuous-speech recognition on a Mac !?
  814. Organization: Lexicon, Inc., Waltham, MA
  815. Date: Wed, 26 Feb 1992 05:48:17 GMT
  816.  
  817. From: dks@athena.mit.edu (dks=)
  818. Newsgroups: comp.sys.mac.system
  819. Subject: WSJ article on Apple's speech-recognition work
  820. Date: 25 Feb 92 15:06:14 GMT
  821. Organization: Massachusetts Institute of Technology
  822. Nntp-Posting-Host: e40-008-9.mit.edu
  823.  
  824.  
  825.  
  826.  Apple - Unveils 'breakthroughs' in technology
  827. {The Wall Street Journal, 24-Feb-92, p. A3}
  828.  
  829. > Apple CEO John Sculley said the company had achieved "a
  830. > major breakthrough" by getting its Macintosh computers to
  831. > respond to commands spoken by people using ordinary
  832. > language. Leading computer researchers hailed Apple's
  833. > work, saying it appeared to represent a milestone in the
  834. > decades-long quest to build personal computers that can
  835. > carry out spoken instructions. "As far as I know, this is
  836. > a first," said Marvin Minsky, a computer-science
  837. > professor at the Massachusetts Institute of Technology.
  838. > Mr. Minsky, along with about 500 other people, witnessed
  839. > a demonstration of Apple's technology at the Technology,
  840. > Entertainment and Design conference in Monterey, Calif.,
  841. > Friday evening. About 24 hours earlier, Apple conducted a
  842. > similar demonstration at a Tokyo trade show. Several
  843. > companies, most notably Dragon Systems Inc., already sell
  844. > speech-recognizers for personal computers, but these
  845. > products require special hardware and a speaker must
  846. > "train" these systems to respond to his or her voice.
  847. > Also, these products work well only when speakers say one
  848. > word at a time, pausing after each one. On the other
  849. > hand, Apple's speech-recognizer responded to continuous
  850. > speech, even answering back at times. Mr. Sculley said
  851. > the system works with off-the-shelf Macintosh computers
  852. > without any special hardware such as a
  853. > digital-signal-processor chips and immediately responds
  854. > to a new speaker's voice. It isn't clear how quickly
  855. > Apple can bring its speech-recognizer technology to
  856. > market or whether the company has a significant advantage
  857. > over other rivals. Mr. Sculley described the
  858. > demonstration as a "teaser" that illustrated Apple's
  859. > progress in building what it has called a "knowledge
  860. > navigator," or a pocket-sized computer that can both
  861. > respond to commands and answer questions in ordinary
  862. > language. Mr. Sculley would not comment on the company's
  863. > plans for speech recognition, but he cites Apple's work
  864. > as evidence of continuing innovation in the field of
  865. > personal computing. Observers said that Apple's
  866. > technology should end up in future Macintosh computers or
  867. > in an expected line of "personal electronics," portable
  868. > devices that will serve as electronic notepads or
  869. > electronic references and include some of the functions
  870. > of a cellular telephone. The only potential drawback is
  871. > that the speech processor, at least today, requires a
  872. > top-of-the-line 68040 processor from Motorola, which
  873. > means that any speach-capable computers would sell for
  874. > more than $5,000. "It looks like superb work ... We can't
  875. > do it in our lab," said Wayne Rosing, who heads the
  876. > advanced research lab at Sun Microsystems. Key figure
  877. > Kai-fu Lee, shrugging off compliments, said the
  878. > speech-recognizer could use stand some improvement.
  879. > Untutored speakers might be confused about how to talk to
  880. > their computer without a better interface, "a developed
  881. > model that cues you in on what to say," he said. The
  882. > vocabulary of the system could also be expanded. Mr. Lee
  883. > said that each type of command, such as opening documents
  884. > or inserting words into forms, was associated with
  885. > anywhere from 100 words to 300 words. He did not give the
  886. > size of the system's total vocabulary. Another problem:
  887. > making the speech-recognizer robust enough that
  888. > background noise doesn't throw it off. Apple's
  889. > speech-recognizer requires speakers to begin each command
  890. > by addressing the computer with a prearranged name. Mr.
  891. > Lee's name for his computer helper, or agent, is
  892. > "Casper." At one point in the demonstration, Mr. Lee
  893. > asked Casper to pay two bills electronically, and he
  894. > specified the amount of each check. Mr. Lee's request was
  895. > carried out.
  896.  
  897.  
  898. EOF
  899. --
  900. Dhanesh
  901.  <dks@mit.edu>
  902.  
  903. --
  904. -- 
  905. "The Beatles were elevator music in my lifetime 'Yummy Yummy Yummy (I've Got
  906. Love In My Tummy)' had more impact on me" -- Michael Stipe of R.E.M.
  907. jb@lexicon.com
  908.  
  909.  
  910.  
  911. - -------------------------
  912.  
  913. From: fry@zariski.harvard.edu (David Fry)
  914. Subject:  Speaker-independent continuous-speech recogni
  915. Date: 26 Feb 92 19:20:51 GMT
  916. Organization: Harvard Math Department
  917.  
  918.  
  919. As I understand it (and I'm no speech expert), Kai-fu Lee's
  920. SPHINX was/is regarded as on, if not "the," leading edge of
  921. speech recognition.  To answer someone else's question, it is
  922. based on hidden markov models.  Several years ago it gave some
  923. impressive results, but none as good as what Apple has
  924. reported now.
  925.  
  926. For the interested, hidden markov models for speech
  927. are described in the survey article "A tutorial on hidden
  928. markov models and selected applications in speech
  929. recognition" by Lawrence Rabiner in Proceedings of the IEEE
  930. vol.77 no. 2 (Feb. 1989), pages 257-285.  There are references
  931. listed there that describe SPHINX in detail, e.g.
  932. "Large-vocabulary speaker-independent continuous speech
  933. recognition," by K.F. Lee and H.W. Hon, in Conf. Proc. IEEE
  934. Int. Conf. on Acoustics, Speech, and Signal Processing, pp
  935. 1205-1208, April 1985.
  936.  
  937. As a slightly educated observer, I think Apple has a good leg
  938. up on the competition.
  939.  
  940.  
  941. David Fry                               fry@math.harvard.EDU
  942. Department of Mathematics               fry@huma1.bitnet
  943. Harvard University                      ...!harvard!huma1!fry
  944. Cambridge, MA  02138            
  945.  
  946.  
  947.  
  948. - -------------------------
  949.  
  950. From: fry@zariski.harvard.edu (David Fry)
  951. Subject:  Speaker-independent continuous-speech recogni
  952. Date: 26 Feb 92 19:24:28 GMT
  953. Organization: Harvard Math Department
  954.  
  955. >"Large-vocabulary speaker-independent continuous speech
  956. >recognition," by K.F. Lee and H.W. Hon, in Conf. Proc. IEEE
  957. >Int. Conf. on Acoustics, Speech, and Signal Processing, pp
  958. >1205-1208, April 1985.
  959.  ^^^^^^^^^^^^^^^^^^^^^
  960.  
  961. Oops...that should be pp 123-126, April 1988.
  962.  
  963.  
  964. David Fry                               fry@math.harvard.EDU
  965. Department of Mathematics               fry@huma1.bitnet
  966. Harvard University                      ...!harvard!huma1!fry
  967. Cambridge, MA  02138            
  968.  
  969.  
  970.  
  971. - -------------------------
  972.  
  973. From: amanda@visix.com (Amanda Walker)
  974. Subject:  Speaker-independent continuous-speech recognition on a Mac !?
  975. Date: 26 Feb 92 23:29:36 GMT
  976. Organization: Visix Software Inc., Reston, VA
  977.  
  978. mitsu@nic.cerf.net (Mitsuharu Hadeishi) writes:
  979. > I'm sure it is not nearly as
  980. > impossible-sounding as it sounds, but I'd like to know just
  981. > how powerful this technology is (vocabulary size, speed,
  982. > etc.)  Who developed this?  Is it based on any existing
  983. > speech-recognition theory (Hidden Markov Models, neural-network
  984. > based solutions, etc.), or what?
  985.  
  986. Well, based on what I know of the state of the art, a Quadra 900 with a
  987. DSP chip and a boatload of RAM could do it (in fact, I believe this is
  988. what was used for the demo).  My educated guess would be a fast FFT
  989. running in the DSP, a homomorphic vocoder running on the 040 (or maybe
  990. another DSP), and a large Markov vocabulary model in the 040's RAM, with
  991. the tables compressed as far as they could go and still keep up in real
  992. time.  It would probably take about 16-32 megs of RAM.  (the quote of 1M
  993. that someone else made is ludicrous unless the vocabulary is severely
  994. limited [say, 1K words]).  I also doubt if they break 90% accuracy with
  995. a large vocabulary.
  996.  
  997. In short, a souped-up Quadra has the raw horsepower, but the
  998. technology's not quite ready to put into an INIT just yet :).
  999.  
  1000. Just for reference, the prevailing view of Apple's speech research that
  1001. I've heard from others in the field seems to be "could be neat stuff,
  1002. but not at the leading edge of performance yet."
  1003.  
  1004.  
  1005. Amanda Walker                              amanda@visix.com
  1006. Visix Software Inc.                    ...!uupsi!visix.com!amanda
  1007. -- 
  1008. "Copyright infringement is the sincerest form of flattery."    --Matt Groening
  1009.  
  1010.  
  1011.  
  1012. - -------------------------
  1013.  
  1014. From: sasdtm@stthomas.unx.sas.com (Donald T. Major)
  1015. Subject:  Speaker-independent continuous-speech recognition on a Mac !?
  1016. Date: 27 Feb 92 19:55:56 GMT
  1017. Organization: SAS Institute Inc.
  1018.  
  1019. All the posts quote Apple as claiming 1 meg of RAM for the product; of
  1020. course, the article also seems to claim that a relatively small vocab
  1021. was used for the demo (I seem to recall seeing the figure of 2-300
  1022. words being mentioned--the article DID say that it wasn't explicitly
  1023. made clear by Apple).
  1024.  
  1025. -- 
  1026. Donald Major       SAS Institute Inc.  "Cicely, let's fling something!"
  1027. sasdtm@unx.sas.com SAS Campus Drive                 - Northern Exposure
  1028. (919) 677-8000     Cary, NC 27513-2414
  1029.  
  1030.  
  1031.  
  1032. - -------------------------
  1033.  
  1034. From: davidm@sfsuvax1.sfsu.edu (David Morgenstern)
  1035. Subject:  Speaker-independent continuous-speech recognition on a Mac !?
  1036. Date: 27 Feb 92 21:23:10 GMT
  1037. Organization: San Francisco State University
  1038.  
  1039. I seem to remember some discussion last year about the other side
  1040. of Oskar (?) which is cool voice synthesis. Has anyone seen this
  1041. (or heard it)? I thought that the posting said that the work was
  1042. based on a different approach to that of other synthesis work...?
  1043.  
  1044. Anyone? HAL?
  1045.  
  1046. daviD
  1047. -- 
  1048. *****     David Morgenstern (a.k.a. BMUG CheerLeader)     *****
  1049. *     CIS: 72030,1607   AOL: daviD eM   FAX: 510-849-9026     *
  1050.  
  1051.  
  1052.  
  1053. - -------------------------
  1054.  
  1055. From: torrie@cs.stanford.edu (Evan Torrie)
  1056. Subject:  Speaker-independent continuous-speech recognition on a Mac !?
  1057. Organization: CS Department, Stanford University, California, USA
  1058. Date: 28 Feb 92 06:33:38 GMT
  1059.  
  1060. davidm@sfsuvax1.sfsu.edu (David Morgenstern) writes:
  1061.  
  1062. >I seem to remember some discussion last year about the other side
  1063. >of Oskar (?) which is cool voice synthesis. Has anyone seen this
  1064. >(or heard it)? I thought that the posting said that the work was
  1065. >based on a different approach to that of other synthesis work...?
  1066.  
  1067.   I wish Apple would release this, and get rid of Macintalk for
  1068. ever.  I have people who are interested in Berkeley Systems
  1069. outSpoken product, but are waiting for a more stable product
  1070. than Macintalk.  An Apple rep I know has been promising this
  1071. for about the past six months.
  1072.    MacWeek had a small piece about it a few weeks ago - it apparently
  1073. uses digitised phonemes.
  1074.  
  1075. -- 
  1076. - ----------------------------------------------------------------------------
  1077. Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu 
  1078. Rains RCC - "Remember, even if you win the rat race, you're still a rat."
  1079.  
  1080.  
  1081.  
  1082. - -------------------------
  1083.  
  1084. From: mxmora@unix.SRI.COM (Matt Mora)
  1085. Subject:  Speaker-independent continuous-speech recogni
  1086. Date: 28 Feb 92 17:42:50 GMT
  1087. Organization: SRI International, Menlo Park, California
  1088.  
  1089. In article <1992Feb26.142053.9196@husc3.harvard.edu> fry@zariski.harvard.edu (David Fry) writes:
  1090. >
  1091. >As I understand it (and I'm no speech expert), Kai-fu Lee's
  1092. >SPHINX was/is regarded as on, if not "the," leading edge of
  1093. >speech recognition.  To answer someone else's question, it is
  1094. >based on hidden markov models.  Several years ago it gave some
  1095. >impressive results, but none as good as what Apple has
  1096. >reported now.
  1097.  
  1098. Wasn't there a movie on the QuickTime CD that showed the technology
  1099. apple was using for Speach recognition? They showed a graphic
  1100. view of speach and how certain patterns can be recognized.
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106. Matt
  1107.  
  1108.  
  1109.  
  1110. -- 
  1111. ___________________________________________________________
  1112. Matthew Mora                |   my Mac  Matt_Mora@sri.com
  1113. SRI International           |  my unix  mxmora@unix.sri.com
  1114. ___________________________________________________________
  1115.  
  1116.  
  1117.  
  1118. - -------------------------
  1119.  
  1120. From: lsr@apple.com (Larry Rosenstein)
  1121. Subject:  Speaker-independent continuous-speech recognition on a Mac !?
  1122. Date: 29 Feb 92 02:50:08 GMT
  1123. Organization: Taligent Inc.
  1124.  
  1125. In article <khaw.699047090@parcplace.com>, khaw@parcplace.com (Mike Khaw)
  1126. writes:
  1127. > I haven't seen the WSJ article. I started to skim a short article in
  1128. > the San Jose Mercury (2/25/92) about it, but lost interest when I read
  1129. > where it said something about speaker-independent discrete word
  1130. > recognition from a limited/restricted vocabulary.
  1131.  
  1132. The following was posted on AppleLink:
  1133.  
  1134. Tune in to "Good Morning America" on Monday, from 7:15 to 7:21 a.m. to watch
  1135. John Sculley demonstrate Apple's speech recognition technology. John and Kai-Fu
  1136. Lee, manager of speech and language technologies, ATG, will show the technology
  1137. that has gotten so much coverage in the press lately as a result of their demos
  1138. at the TED3 Conference last week in Monterey, and recently in Tokyo.
  1139. --
  1140. Larry Rosenstein
  1141. lsr@apple.com
  1142.  
  1143.  
  1144.  
  1145. - -------------------------
  1146.  
  1147. From: amanda@visix.com (Amanda Walker)
  1148. Subject:  Speaker-independent continuous-speech recogni
  1149. Organization: Visix Software Inc., Reston, VA
  1150. Date: Fri, 28 Feb 92 21:26:53 GMT
  1151.  
  1152. fry@zariski.harvard.edu (David Fry) writes:
  1153. > As I understand it (and I'm no speech expert), Kai-fu Lee's
  1154. > SPHINX was/is regarded as on, if not "the," leading edge of
  1155. > speech recognition.
  1156.  
  1157. The latest word I had was that they were running at about #3, with BBN
  1158. and someone else whose name escapes me at the moment playing tag for #1.
  1159. I'm sure they had a spiffy demo, but I won't believe "revolutionary"
  1160. claims until I see some hard numbers, such as:
  1161.  
  1162. How well do they do on something like the NSA standard test data?
  1163. Do they break 95% accuracy on 100,000+ word vocabulary?
  1164. How much memory does such a vocabulary take, and how much of the CPU
  1165. does the recognizer suck down?
  1166.  
  1167. Voice recognition that's good enough for navigation and simple task
  1168. invocation is much easier that voice recognition that's good enough for,
  1169. say, dictation.  The first isn't exciting--the second is.
  1170.  
  1171.  
  1172. Amanda Walker                              amanda@visix.com
  1173. Visix Software Inc.                    ...!uupsi!visix.com!amanda
  1174. -- 
  1175. "Do not meddle in the affairs of wizards, for it makes them soggy and hard
  1176.  to light."    --Robert Anton Wilson
  1177.  
  1178.  
  1179.  
  1180. - -------------------------
  1181.  
  1182. From: russotto@eng.umd.edu (Matthew T. Russotto)
  1183. Subject:  Speaker-independent continuous-speech recognition on a Mac !?
  1184. Date: Sun, 01 Mar 92 02:06:26 GMT
  1185. Organization: University of Maryland, College Park, College of Engineering
  1186.  
  1187. In article <20976@goofy.Apple.COM> lsr@apple.com (Larry Rosenstein) writes:
  1188. >The following was posted on AppleLink:
  1189. >
  1190. >Tune in to "Good Morning America" on Monday, from 7:15 to 7:21 a.m. to watch
  1191. >John Sculley demonstrate Apple's speech recognition technology. John and Kai-Fu
  1192. >Lee, manager of speech and language technologies, ATG, will show the technology
  1193. >that has gotten so much coverage in the press lately as a result of their demos
  1194. >at the TED3 Conference last week in Monterey, and recently in Tokyo.
  1195.  
  1196. Don't take this personally, but "Any sufficiently advanced technology is
  1197. indistinguishable from a rigged demo".... (and: caveat emptor)
  1198.  
  1199.  
  1200. -- 
  1201. Matthew T. Russotto    russotto@eng.umd.edu    russotto@wam.umd.edu
  1202. Some news readers expect "Disclaimer:" here.
  1203. Just say NO to police searches and seizures.  Make them use force.
  1204. (not responsible for bodily harm resulting from following above advice)
  1205.  
  1206.  
  1207.  
  1208. - -------------------------
  1209.  
  1210. From: gourdol@imag.imag.fr (Arno Gourdol)
  1211. Subject:  Speaker-independent continuous-speech recognition on a Mac !?
  1212. Date: 1 Mar 92 10:01:51 GMT
  1213. Organization: IMAG Institute, University of Grenoble, France
  1214.  
  1215. davidm@sfsuvax1.sfsu.edu (David Morgenstern) writes:
  1216.  
  1217. >I seem to remember some discussion last year about the other side
  1218. >of Oskar (?) which is cool voice synthesis. Has anyone seen this
  1219. >(or heard it)? I thought that the posting said that the work was
  1220. >based on a different approach to that of other synthesis work...?
  1221.  
  1222. >Anyone? HAL?
  1223.  
  1224. Oskar? Casper, you mean? Anyway, yes I have heard the MacIntalk
  1225. replacement, last year at the WWDC and it was supposed to be made
  1226. beta-available during last summer. The quality of the speech was
  1227. somewhat better than Macintalk, pefectly understandable, but 
  1228. yet nottotaly human. Anyway, researchs tend to prove that people
  1229. EXPECT computers to speak with a computer voice and that they may
  1230. be surprised if their computer really speaks like a human.
  1231. The speech synthetiser was also able to do TTS (text to speech)
  1232. conversion, ie to read aloud text. Also, you can customize the
  1233. voice: ie have a male voice, a female voice, a child voice, or
  1234. even different voices per application.
  1235. I'm not 100% sure I remember correctly, but the technique used
  1236. was to blur two consecutive syllabus sounds to make a new di-sylabus.
  1237. To say 'pie' you would blur a digital sampling of 'p' with a
  1238. sampling of 'i'. That's a technique that has already been used
  1239. by at least a research laboratory in France (France Telecom)
  1240. for French. BTW, this technique is localizable, ie it can work
  1241. with different languages than English.
  1242. The memory requirements were 400 Kb in RAM.
  1243.  
  1244. Arno.
  1245.  
  1246.  
  1247. -- 
  1248. Arno Gourdol.  <Gourdol@imag.fr>
  1249. Minds, like parachutes, only function when open.
  1250.  
  1251.  
  1252.  
  1253. - -------------------------
  1254.  
  1255. From: keith@Apple.COM (Keith Rollin)
  1256. Subject:  Speaker-independent continuous-speech recognition on a Mac !?
  1257. Date: 2 Mar 92 22:10:10 GMT
  1258. Organization: Apple Computer Inc., Cupertino, CA
  1259.  
  1260. In article <1992Mar01.020626.17992@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes:
  1261. >In article <20976@goofy.Apple.COM> lsr@apple.com (Larry Rosenstein) writes:
  1262. >>The following was posted on AppleLink:
  1263. >>
  1264. >>Tune in to "Good Morning America" on Monday, from 7:15 to 7:21 a.m. to watch
  1265. >>John Sculley demonstrate Apple's speech recognition technology. John and Kai-Fu
  1266. >>Lee, manager of speech and language technologies, ATG, will show the technology
  1267. >>that has gotten so much coverage in the press lately as a result of their demos
  1268. >>at the TED3 Conference last week in Monterey, and recently in Tokyo.
  1269. >
  1270. >Don't take this personally, but "Any sufficiently advanced technology is
  1271. >indistinguishable from a rigged demo".... (and: caveat emptor)
  1272.  
  1273. True, but... As I understand from a conversation at lunch today, the
  1274. Macintosh was able to understand voice input from the show's host (Joan
  1275. London?) without any training. And to accent the "realness" of the
  1276. demo, I understand that the voice synthesis of the Macintosh sucked the
  1277. big one (Macintalk quality or worse). If it were a rigged demo, you can
  1278. bet they'd be using digitized responses (_I_ wouldn't bet, but _you_
  1279. can).
  1280.  
  1281. I didn't see the show myself; all of this is second hand.
  1282.  
  1283. -- 
  1284. - ----------------------------------------------------------------------------
  1285. Keith Rollin           ---            <Taligent .signature under construction>
  1286. Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...
  1287.  
  1288.  
  1289.  
  1290. - -------------------------
  1291.  
  1292. From: amanda@visix.com (Amanda Walker)
  1293. Organization: Visix Software Inc., Reston, VA
  1294. Date: Mon, 2 Mar 92 21:39:02 GMT
  1295.  
  1296. sasdtm@stthomas.unx.sas.com (Donald T. Major) writes:
  1297. > All the posts quote Apple as claiming 1 meg of RAM for the product; of
  1298. > course, the article also seems to claim that a relatively small vocab
  1299. > was used for the demo (I seem to recall seeing the figure of 2-300
  1300. > words being mentioned--the article DID say that it wasn't explicitly
  1301. > made clear by Apple).
  1302.  
  1303. With that small a vocabulary, it's quite practical, and I'm quite
  1304. willing to believe their claims.  This would, however, limit its
  1305. usefulness as well.  Even so, it would be quite a studly addition to Mac
  1306. system software...
  1307.  
  1308.  
  1309. Amanda Walker                              amanda@visix.com
  1310. Visix Software Inc.                    ...!uupsi!visix.com!amanda
  1311. - -- 
  1312. It is a vast and wonderful universe, but you wouldn't know it to live here.
  1313.  
  1314. - -------------------------
  1315.  
  1316. From: torrie@cs.stanford.edu (Evan Torrie)
  1317. Organization: CS Department, Stanford University, California, USA
  1318. Date:  3 Mar 92 06:01:53 GMT
  1319.  
  1320. keith@Apple.COM (Keith Rollin) writes:
  1321.  
  1322. >True, but... As I understand from a conversation at lunch today, the
  1323. >Macintosh was able to understand voice input from the show's host (Joan
  1324. >London?) without any training. And to accent the "realness" of the
  1325. >demo, I understand that the voice synthesis of the Macintosh sucked the
  1326. >big one (Macintalk quality or worse). 
  1327.  
  1328.   Macintalk quality or worse?!?  I watched the show, and although
  1329. the synthesis was stilted, it was 10 times better than Macintalk!
  1330. Now, if only Apple would release it (the Text-To-Speech - I can wait
  1331. for the voice recognition part).
  1332.  
  1333. >-- 
  1334. >------------------------------------------------------------------------------
  1335. >Keith Rollin           ---            <Taligent .signature under construction>
  1336.                                         ^^^^^^^^^^^^^^^^^^^^
  1337.   I thought Taligent officially came into existence today (or was
  1338. it last week?).
  1339.  
  1340. - -- 
  1341. - ------------------------------------------------------------------------------
  1342. Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu 
  1343. "I feel slimy already." - John Sununu, on being welcomed by journalists to
  1344. his new role at CNN's Crossfire.
  1345.  
  1346. - -------------------------
  1347.  
  1348. From: russotto@eng.umd.edu (Matthew T. Russotto)
  1349. Date: Tue, 03 Mar 92 14:19:24 GMT
  1350. Organization: University of Maryland, College Park, College of Engineering
  1351.  
  1352. In article <63413@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes:
  1353. >
  1354. >True, but... As I understand from a conversation at lunch today, the
  1355. >Macintosh was able to understand voice input from the show's host (Joan
  1356. >London?) without any training.
  1357.  
  1358. Supposedly.  She seemed to be reading from a script, however.  A few times
  1359. "Casper" messed up and failed to respond.  But, if I was rigging a demo of
  1360. a prototype, I might do that too...
  1361.  
  1362. >And to accent the "realness" of the
  1363. >demo, I understand that the voice synthesis of the Macintosh sucked the
  1364. >big one (Macintalk quality or worse). If it were a rigged demo, you can
  1365. >bet they'd be using digitized responses (_I_ wouldn't bet, but _you_
  1366. >can).
  1367.  
  1368. It wasn't worse than Macintalk quality.  It certainly wasn't digitized, though.
  1369. Then again, if I was rigging a demo, I could think of that too...
  1370.  
  1371. What it comes down to is that a real breakthrough and a rigged demo are
  1372. indistinguishable on TV.  So when does Casper tour the country? :-)
  1373.  
  1374. - -- 
  1375. Matthew T. Russotto    russotto@eng.umd.edu    russotto@wam.umd.edu
  1376. Some news readers expect "Disclaimer:" here.
  1377. Just say NO to police searches and seizures.  Make them use force.
  1378. (not responsible for bodily harm resulting from following above advice)
  1379.  
  1380. - -------------------------
  1381.  
  1382. From: amanda@visix.com (Amanda Walker)
  1383. Organization: Visix Software Inc., Reston, VA
  1384. Date: Wed, 4 Mar 92 05:02:51 GMT
  1385.  
  1386. keith@Apple.COM (Keith Rollin) writes:
  1387. > True, but... As I understand from a conversation at lunch today, the
  1388. > Macintosh was able to understand voice input from the show's host (Joan
  1389. > London?) without any training.
  1390.  
  1391. This isn't surprising.  Most current systems are quite
  1392. speaker-independent, although most work a little better with separate
  1393. male and female front ends.  It's the "continuous" bit that's a real
  1394. bear to get working.  Continuous human speech is much more complex than
  1395. it seems at first glance.  'Phonemes' don't really exist in any useful
  1396. sense, for example.
  1397.  
  1398. [And yes, I do know something about phonetics and phonology--they just
  1399.  turn out to be much more useful to humans than to computers :)]
  1400.  
  1401. Amanda Walker                              amanda@visix.com
  1402. Visix Software Inc.                    ...!uupsi!visix.com!amanda
  1403. - -- 
  1404. UNIX: The only operating system that can be destroyed by mail.
  1405.  
  1406. - -------------------------
  1407.  
  1408. From: asp%trail.sharpstone.com@uu.psi.com (Alexandre Sasha Polozoff)
  1409. Date: Tue, 3 Mar 92 13:03:32 GMT
  1410. Organization: Sharpstone Trail Productions - Austin Texas USA
  1411.  
  1412.  
  1413. > True, but... As I understand from a conversation at lunch today, the
  1414. > Macintosh was able to understand voice input from the show's host (Joan
  1415. > London?) without any training. And to accent the "realness" of the
  1416. > demo, I understand that the voice synthesis of the Macintosh sucked the
  1417. > big one (Macintalk quality or worse). If it were a rigged demo, you can
  1418. > bet they'd be using digitized responses (_I_ wouldn't bet, but _you_
  1419. > can).
  1420.  
  1421.  
  1422. The Mac did recognize Joan's voice.  Although it faltered once.
  1423.  
  1424. You are right.  The synthesized voice was *awful*.  I would never
  1425. be able to handle listening to it.
  1426.  
  1427.  
  1428. - --------------------------------------------------------------------------
  1429. Alexandre Sasha Polozoff            Internet    asp@trail.sharpstone.com
  1430.                                     CI$            73467,252
  1431.                                     Voice        512/218-1178
  1432. - --------------------------------------------------------------------------
  1433. Sharpstone Trail Productions        info@sharpstone.com
  1434. 8903 Sharpstone Trail               uunet!trail.sharpstone.com!info
  1435. Austin, TX  78717                    
  1436. - --------------------------------------------------------------------------
  1437.  
  1438. - -------------------------
  1439.  
  1440. From: jmatthews@desire.wright.edu
  1441. Date: 5 Mar 92 18:41:40 GMT
  1442. Organization: Wright State University
  1443.  
  1444. In article <1992Mar03.141924.18207@eng.umd.edu>, russotto@eng.umd.edu (Matthew T. Russotto) writes:
  1445. ...
  1446. > Supposedly.  She seemed to be reading from a script, however.  A few times
  1447. > "Casper" messed up and failed to respond.  But, if I was rigging a demo of
  1448. > a prototype, I might do that too...
  1449.  
  1450. Agreed. One element that seemed distinctly _not_ planned happened at the end of
  1451. the segment. Caspar seemed to be scanning for its name used in direct address
  1452. as a clue to start listening for a command. After the demo Joan and guests were
  1453. chatting and Sculley used the name Caspar in a way that (inadvertantly)
  1454. triggered the machine. Caspar responded and Joan used the ensuing confusion to
  1455. thank everyone and cut to commercial.
  1456.  
  1457. Several questions arise:
  1458.  
  1459. - - is it Caspar or Casper?
  1460. - - can I change the trigger "Caspar" to something else like "Igor" or "Flunky"?
  1461.  
  1462. o----------------------------------------------------------------------------o
  1463. | John B. Matthews, jmatthews@desire.wright.edu, disclaimer:= myViews <> WSU |
  1464. | "I'm a commensal .sig virus, indistinguishable from an ordinary organelle."|
  1465. o----------------------------------------------------------------------------o
  1466.  
  1467. +++++++++++++++++++++++++++
  1468.  
  1469. From: jpugh@apple.com (Jon Pugh)
  1470. Date: 6 Mar 92 20:31:45 GMT
  1471. Organization: Apple Co.
  1472.  
  1473. In article <63413@apple.Apple.COM>, keith@Apple.COM (Keith Rollin) writes:
  1474. > >Don't take this personally, but "Any sufficiently advanced technology is
  1475. > >indistinguishable from a rigged demo".... (and: caveat emptor)
  1476. > True, but... As I understand from a conversation at lunch today, the
  1477. > Macintosh was able to understand voice input from the show's host (Joan
  1478. > London?) without any training. And to accent the "realness" of the
  1479. > demo, I understand that the voice synthesis of the Macintosh sucked the
  1480. > big one (Macintalk quality or worse). If it were a rigged demo, you can
  1481. > bet they'd be using digitized responses (_I_ wouldn't bet, but _you_
  1482. > can).
  1483. > I didn't see the show myself; all of this is second hand.
  1484.  
  1485. I just went down and got my t-shirt for donating my voice to Casper.  I had
  1486. to read a list of 300 phrases into a couple of microphones placed in a
  1487. variety of locations.  The phrases were business and Macintosh oriented with
  1488. common menu items and meeting oriented phrases predominating.
  1489.  
  1490. After it was over, I got to watch a tape of the Good Morning America segment.
  1491. It failed a couple of times, so I am inclined to believe it.  There was a
  1492. time it wouldn't recognize Joan, so Kai-Fu had to say the command, and there
  1493. was another instance where it heard a command that wasn't stated.
  1494.  
  1495. All in all, I thought it was a believable demo of pre-release software,
  1496. complete with standard demo problems.  Now they just need to make the voice
  1497. sound like Majel Barrett.
  1498.  
  1499. Jon
  1500.  
  1501. +++++++++++++++++++++++++++
  1502.  
  1503. From: the.cloud@applelink.apple.com (Ken McLeod)
  1504. Date: 7 Mar 92 09:18:30 GMT
  1505. Organization: Apple Computer, Inc.
  1506.  
  1507. In article <21204@goofy.Apple.COM>, jpugh@apple.com (Jon Pugh) writes:
  1508. > I just went down and got my t-shirt for donating my voice to Casper.  I had
  1509. > to read a list of 300 phrases into a couple of microphones placed in a
  1510. > variety of locations.  The phrases were business and Macintosh oriented with
  1511. > common menu items and meeting oriented phrases predominating.
  1512.  
  1513. Not just phrases... also grunts, coughs, "umm-hmmm"s, and so forth. :-)
  1514.  
  1515. I can verify the "reality" of the Good Morning America demo, having had
  1516. the opportunity to [briefly] play with Casper today. It correctly interpreted
  1517. my normal conversational voice 100% of the time to perform a bunch of tasks
  1518. in the Finder (open and close windows, selecting multiple menu items, and so
  1519. on) without having heard my voice before, or requiring me to think about
  1520. carefully enunciating my phrases. The smoothness of it blew me away, compared
  1521. to my previous experience with using a certain other commercially available
  1522. speech recognition device for the Mac (which often ends up "training" the user
  1523. to speak loudly and deliberately, and always requires "retraining" for other
  1524. users.) Another engineer who was with me managed to duplicate Joan's
  1525. experience on the TV demo, but the problem was explained to us and without
  1526. going into detail, it seems fairly minor.
  1527.  
  1528. Just as as aside, if you saw the demo, you might have gotten the impression
  1529. that every phrase you speak will need to be preceded by a control word (i.e.
  1530. "Casper".) This isn't the case at all.
  1531.  
  1532. >All in all, I thought it was a believable demo of pre-release software,
  1533. >complete with standard demo problems.  Now they just need to make the voice
  1534. >sound like Majel Barrett.
  1535.  
  1536. Agreed. (I did try speaking to Casper in a Patrick Stewart voice. :-)
  1537.  
  1538. - -ken
  1539.  
  1540. ---------------------------
  1541.  
  1542. End of C.S.M.P. Digest
  1543. **********************
  1544.